What changed

No user-facing behavior change. Diagnostic-only: when the AAP decoder receives a message it can't decode, the log line now includes the payload bytes, how long ago the last command was sent, and what that last command was. Makes it possible to correlate unknown device-pushed opcodes with the command that likely triggered them.

Technical Context

• Generic lastSentCommand / lastSentAt tracking recorded in sendRaw, alongside the existing ANC-specific timestamp which still drives ANC debounce logic.
• The old "Unhandled message: cmd=0xNNNN payload=NB" line (DEBUG) is replaced with an INFO line carrying the payload hex, sinceLastSend ms, and the AapCommand subclass that was sent. Bumped to INFO so the signal lands in default debug recordings without bumping the overall verbosity.
• Motivation: AirPods Pro 3 emits several undocumented opcodes (0x004C, 0x0052, 0x0055, a settings-envelope frame with setting ID 0x38) that currently fall through the decoder. Having payload + correlation in the log makes it feasible to build up a response map from field logs instead of having to add a bespoke handler per opcode.
• The symptom that prompted this: SetPersonalizedVolume appears to have no audible effect on Pro 3 and the 0x004C responses captured in earlier logs stop appearing in later sessions — so the correlation data is what we need next to tell "device ignoring our write" apart from "device acked via an opcode we're not decoding".